Ciphering as a part of the multicast concept

ABSTRACT

The invention proposes a method for transmitting a message to a plurality of user entities in a network by using a multicast service, comprising the steps of encrypting a multicast message by using ciphering, and sending the encrypted multicast message to the plurality of user entities simultaneously. The invention also proposes a corresponding multicast service control device and a corresponding user entity.

FIELD OF THE INVENTION

The present invention relates a method for transmitting a message to aplurality of subscribers.

BACKGROUND OF THE INVENTION

The reception of traffic in point to multipoint (PTM) communication istypically organized in the following way:

A potential receiver must become a member of a receiver group (join thegroup) and whenever he wants to quit the reception he must leave thegroup. During the group membership the PTM data reception is possible.Parties not being members do not receive this data. Joining and leavingcan be done whenever wanted. This kind of communication model is calledmulticasting. A special case of multicasting is broadcasting in whichthe data is delivered to all potential receivers.

When multicast communication model is applied to a mobile environment,limiting the data reception only to joined members might become aproblem since the data is delivered over a radio link thus makingeavesdropping possible to non-group members. With encryption thisproblem can be solved by enabling only authorized parties (i.e.receivers that have joined the group) to decrypt the delivered encrypteddata. The decryption is made possible by giving the decryption key onlyto the group members.

The work to standardise the Multicast as a new service has been startedin 3GPP (Third Generation Partnership Project). The aim in this work isto enhance the current capabilities in UTRAN (UMTS terrestrial radioaccess network) (and maybe later also in CN (core network)) the way thatit is also capable of providing such services, which are using thecommon network resources, but which are intended only to a restrictedgroup of people in a cell. These requirements are not fulfilled incurrent Cell Broadcast concept, which is already standardised in 3GPPrelease 99.

Basically the standardisation of the multicast type of service meansthat the new service concept should be capable of transmitting datasimultaneously to a group of people, who previously indicated theirinterest to receive data from a Multicast service. As part of theirindication they also accepted that the service provider is allowed tocharge subscribers for the service (the charging can be based on e.g.monthly fee, the usage time of the multicast service or the amount ofreceived data). It is noted that the service provider can be either theexternal service provider (e.g. a person, community, state, government,company) who does not own the network or operator itself, who owns thenetwork through which multicast data is transmitted.

In one cell the multicast related data is sent at the same time to allsubscribers by using a single communication path on the radio interface.In UTRAN this communication path can consist of e.g. SCCPCH (Secondarycontrol Channel, a physical channel), which is currently used totransmit data from common channels and the FACH (Forward Link AccessChannel, a transport channel), which is devoted for the cell broadcastservices. The main requirement for the used channel is that this channelcan/is allowed to listen more than one UE and it is capable oftransmitting also streaming type of data.

A cell broadcast service is a service type, which is already part of the3GPP release 99. Cell broadcast service uses as a transport channelForward Access Channel (FACH) and on the air interface secondary commonphysical channel (SCCPCH). The cell broadcast service is characterisedby such services, which are not secured or charged from end users by theservice provider (or operators) and each UE in the cell—even if they arein Idle mode—are allowed to listen the data from the air interface,which is belonging to the cell broadcast service. A typical-cellbroadcast service could be e.g. small advertisements, road informationetc.

In order to use such a commonly known channel on the air interface andat the same time to provide e.g. charging, in the multicast scheme itshould be possible for the service providers (or the network) to allowonly the authorised subscribers to access the multicast service. Thismeans that it shall be possible to exclude all unauthorised users fromthe service even if the UE (User Entity) is capable of listening to thephysical channel. For multicast services it has been proposed to useciphering for this purpose.

Ciphering of multicast services is not a similar concept as theciphering that is used for e.g. dedicated channels. When the usedtransport channel is a dedicated transport channel (or a common channelfor DCCH (Dedicated control Channel) or DTCH (Dedicated Traffic Channel)(DCCH and DTCH are both logical channels)), the used securityinformation is sent to the UE upon establishment of the radio bearer(RB). For that purpose, for the UE, the NW has before the actual datatransmission (and also upon that) setup separate signalling connectionsfor the transmission of L3 signalling messages. It is noted that L3stands for Layer 3 (in UTRAN=RRC (Radio Resource Control)), a protocollayer.

The multicast services were not supported by 3GPP rel.99 or rel.4, andtherefore no security procedures for point-to-multipoint services havebeen defined. Also it is not possible to separate between unauthorisedand authorised users from service point of view on such channels, whichare commonly used for multiple UEs.

It is noted that the sharing of the common channels between multiple UEsis possible due to use of UE specific identification in the datamessage. This method however is not feasible as such in this casebecause data is meant to a group of UEs and the use of “group id”instead of UE specific id does not prevent unauthorised UEs to fetchingdata from the shared common channel.

SUMMARY OF THE INVENTION

Thus, the object underlying the invention resides in allowing network toprovide secured multicast services (i.e. point-to-multipoint services).

This object is solved by a method for transmitting a message to aplurality of user entities in a network by using a multicast service,comprising the steps of

encrypting a multicast message by using ciphering, and

sending the encrypted multicast message to the plurality of userentities.

Thus, a multicast message is encrypted. That is, the message can be sentvia a common channel over the network, and only those subscribers whichare allowed to receive this message may decrypt it.

Therefore, the reception of a multicast message, i.e.,point-to-multipoint data is restricted on a specific group ofsubscribers. Moreover, by encrypting the message, also differentmulticast sessions can be established in one cell. That is, differentmulticast services can be offered in the same cell in the same time.

The invention also proposes a multicast service control device fortransmitting a message to a plurality of user entities in a network, byusing a multicast service wherein

the device is adapted to encrypt a multicast message by using ciphering,and to send the encrypted multicast message to the plurality of userentities.

Moreover, the invention proposes a user entity in a network which isadapted to receive an encrypted multicast message transmitted to aplurality of user entities in a network by using a multicast service,and to decrypt the encrypted multicast message by using deciphering.

Furthermore, the invention also proposes a network comprising amulticast service control device described above and at least one userentity described above.

Further advantageous developments are set out in the dependent claims.

In particular, the encrypted multicast message may be decrypted in eachuser entity individually.

The ciphering may be performed by using a ciphering key, wherein theciphering key may be the same for encrypting and decrypting, or a firstciphering key may be used for encrypting whereas a second ciphering keydifferent from the first ciphering key may be used for decrypting.

The ciphering key may be changed in a defined time frame. In this way,security can be improved since the ciphering key is changed regularly.

Ciphering key generation related input parameters may be sent to theuser entity when the user entity registers with a service sendingencrypted messages to a plurality of user entities. Alternatively,ciphering key generation related input parameters may be sent to theuser entity when a transmission of encrypted messages to a plurality ofuser entities is activated. Thus, ciphering key generation related inputparameters can be sent to the user entity by using normal controlsignalling.

It is noted that not all ciphering key generation related inputparameters are sent during one occasion. That is, some parameters may besent during registration of the subscriber, and other parameters may besent on activation of the transmission.

Thus, the actual ciphering key is not sent over the air interface.Instead, basically such ciphering related parameters based on which UEis capable of calculating correct deciphering key are sent.

By sending those parameters, and not the actual ciphering key, securityis improved.

The ciphering key may be stored in a memory of the user entity, or itmay be stored in a subscriber identification module (SIM). The cipheringkey should not be accessible for the user of the user entity. In thisway, the security can be improved.

Moreover to improve security against, e.g., a hacker, at least one inputparameter may be used for encrypting. Such an input parameter maycomprise at least one subscriber related value. Thus, it is ensured thatonly the subscriber to which the value relates is able to decrypt themessage.

The subscriber related value may comprise a group identification foridentifying a whole group of subscribers which are allowed to receivethe message. In this way, the operation load for assigning a subscribervalue to each subscriber individually can be reduced.

The input parameter may comprise at least one service related value.Thus, in this way the multicast message can only be decrypted in casethe user entity knows this service related value. Hence, it can beensured that only those user entities may decrypt the multicast messagewhich have subscribed to the service.

Such a service related value may comprise a service identification foridentifying a service type. The service type denotes a group ofservices. Moreover, the service related value may comprise a subserviceidentification for identifying a particular service.

The input parameter mentioned above may also comprise at least onenetwork related value for identifying a particular network. Furthermore,the input parameter may comprise at least one cell related value foridentifying a particular cell.

The input parameter may also be described in the identification of themulticast data frame (i.e. upon active data transmission). Thisidentification can be e.g. sequence number, timestamp etc. With the aidof the packet related identification the security of the transmissioncan be improved, because the used encryption changes frame by frame.

For decrypting, the input parameter used for encrypting may be used.That is, the same input parameter which was used for encrypting is alsoused for decrypting.

The input parameter may be stored in a memory of the user entity, or/andit may be stored in a subscriber identification module (SIM).

The input parameter should not be accessible for the user of the userentity. In this way, the security can be improved, since the user cannot access the security parameters.

Some or all of the required input parameters may be sent to the userentity upon registering to a service.

Some or all of the required parameters may be sent to the user entity asa control information of the actual multicast data packets (i.e., e.g.,inside the header of the Multicast data frame or as an independentcontrol frame).

The receiving of multicast related data may trigger the start of thedecryption. Alternatively, the start of the decryption may be triggeredby the network, by sending pre-information of a multicast message to besent. Furthermore, the start of the decryption may be triggered by thesubscriber. Thus, three different ways about how the decryption isactually started are proposed. The trigger may be a pin code or apassword.

For encryption an encryption algorithm may be used which uses at least acounter value as an input parameter, which is delivered to the pluralityof user entities. That is, by delivering the counter value to the userentities, the same kind of encryption algorithm as in, e.g., UMTS may beused. In this way, the method according to the invention can easily beapplied to existing schemes. The encryption algorithm may be the f8encryption algorithm.

The counter value may be delivered to the plurality of users unencryptedtogether with encrypted data. Thus, it is not necessary to provideadditional signalling since the counter value is transmitted togetherwith the user data, i.e., the encrypted data packets. That is, thecounter value is delivered in conjunction with the content stream (inplain text via PTM channel), thus enabling the receivers to decrypt thecontent.

Moreover, a session key may be calculated from a shared key and a randomnumber, the session key being used as a further input parameter of theencryption algorithm, and the random number may be updated and sent tothe plurality of user entities at certain times. Thus, the security canbe improved since the random number is changed at certain times.

The random number may be updated at regular time intervals. Thus, thedecryption key can be updated periodically. With this approach, noadditional point to point signalling between the network and theterminal is required and thus network resources are saved.

Furthermore, the random number may be delivered unencrypted to theplurality of users. Thus, the procedure can be simplified since no extraencryption/decryption of the random number is necessary.

The shared key may be delivered to the plurality of users via a securechannel using a point-to-point connection. Thus, the security can beimproved, since the shared key is not sent via multicast.

A bearer identifier may be used as a further input parameter for theencryption algorithm, and the bearer identifier may be delivered to theplurality of users via a secure channel.

The multicast message may be sent via a single physical channel.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will be more readily understood with reference tothe accompanying drawings in which:

FIG. 1 illustrates two cells of a network in which the embodiments ofthe invention can be applied,

FIG. 2 shows ciphering of user and signalling data transmitted overradio access link for point-to-point services,

FIG. 3 shows a model to cipher data according to the first embodiment,wherein the cipher data is transmitted by using point-to-multipointconnection, and

FIG. 4 shows signalling diagram according to the second embodiment.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In the following, preferred embodiments of the invention is described inmore detail with reference to the accompanying drawings.

FIG. 1 illustrates a simplified example, wherein a multicast serviceprovider sends messages to a plurality of UE's (User Entities) A to M byusing multicast. UE's A to G are located in a cell C1, whereas UE's H toM are located in a cell C2.

According to the invention, for the multicast transmission the followingrequirements are seen valid:

-   -   Multicast data should be transmitted through one physical        channel, the configuration information of which (i.e. Transport        Formats, used codecs etc) is common knowledge.    -   It should be possible to separate authorised and unauthorised        users of the cell.    -   It should be possible to establish several different multicast        sessions in a cell (e.g. containing video clips, music, etc.)        and the user shall be able to select which multicast session to        receive.    -   It should be possible to make out different multicast sessions,        even though they are using the same network resources e.g. on        the air interface.

These requirements define that it should be possible for theoperator/service provider to control the transmission of the multicasttype of data in such a way that only subscribers which have registeredwith the multicast service are the only ones to get it as well. This isa new service concept which is not provided for in the current cellbroadcast service and therefore new procedures are required.

One such procedure is the use of the ciphering for the multicastservices. With the aid of ciphering the authorised and unauthorisedusers can be separated as well as distinction made between differentservices. However, because the current ciphering is designed for thepoint-to-point connections, some modifications are required to thecurrent security procedure regarding:

-   -   Ciphering key allocation    -   Input parameters for ciphering algorithms    -   Management of the ciphering keys.        (Note: The changes could be done also by considering the        security concept (i.e. symmetric versus asymmetric ciphering))

Next, the ciphering key allocation according to the first embodiment isdescribed in more detail.

There are a plurality of possibilities when the information, which canbe used to define the correct multicast ciphering key (Ck), can beallocated to the subscriber (i.e., the User Entity (UE)).

One possibility is when the subscriber registers with the multicastservice (e.g. by WLAN, Internet, phone call, letter, personal visitetc.), based on registration the either the external service provider oroperator configures the subscriber's UE to receive subscribed type ofmulticast services. This can be made e.g. by using config SMS orpersonally at the operators/service providers premises. A config SMS isan SMS (Short Message Service) type, which can be transparent to thesubscriber (or reception of such SMS is agreed by the subscriber e.g.upon time when SMS is received) but which can change the information orconfiguration of the UE. This SMS is always sent upon RRC connectedstate and therefore it is ciphered by using the methods which has beendefined already in 3GPP rel.99 and rel 4/5.

Another possibility is to give the information to the subscriber (UE)each time before the multicast data transmission is activated, i.e.inside the precontrol information sent to the UE (e.g. in the RRCsignalling message). As an alternative the ciphering key related inputparameters can also be sent by the Core network (CN) to the UE in theMM/SM (Mobility Management/Session management) level signalling message.MM and SM are functionalities in CN.

Alternatively, the information can be delivered to the UE as the peer topeer signalling connections between layers to support multicast datatransmission on UTRAN and UE side. Such a layer does not exist yet,because the 3GPP RAN working groups have not yet made any decision toinclude such a layer. This layer can be a new layer or it can be e.g.the enhanced BMC layer.

Based on the sent information the UE can generate the correct Ck for theservice.

Next, the input parameters for the ciphering algorithms used by aciphering unit according to the first embodiment are described in moredetail.

The ciphering unit is a unit either in CN or UTRAN, which consists ofencryption algorithm, which uses specific input parameters to performrequired ciphering transaction to the data meant to be encrypted.

In particular, modified input parameters for the ciphering unit arerequired. The parameters are described by referring to FIGS. 2 and 3.

FIG. 2 shows ciphering of user and signalling data transmitted over theradio access link for point-to-point services, as defined in TS 33.102.

As shown in FIG. 2, a plaintext is encrypted by applying a keystreamusing bit per bit binary addition of the plaintext and the keystream.The keystream is generated by using the ciphering algorithm f8, whichuses a ciperhing key Ck and various input parameters COUNT-C, BEARER,DIRECTION, LENGTH etc.

To support encryption for such services as the multicast services thecurrently used set of input parameters COUNT-C, DIRECTION and BEARERused in the ciphering unit are not applicable any more.

-   -   COUNT-C is a time dependent input, which consist of the MAC-d        HFN (Hyper Frame Number, a parameter) value and CFN (Connection        Frame Number, a parameter used by such services, which are using        transparent RLC mode) or SFN (Sequence Frame Number, a parameter        used by such services, which are using either unacknowledged or        acknowledged RLC mode), which both are dependent of the current        state of the data transmission and the transmission instance on        the air interface. It is noted that HFN is a Hyper Frame Number,        which is a parameter, CFN is a Connection Frame Number and SFN        is a Sequence Frame Number, which are also a parameters. For        point-to-point connections these kinds of values are possible to        define, because UE and NW (Network) are synchronised at the        beginning of the connection (i.e. both ends know from which        value the counting of HFN and CFN/SFN should be started). In        case of multicast, such synchronisation is problematic to        arrange and therefore no time dependent input parameters can be        used for multicast ciphering. Therefore, this not used in the        first embodiment. Nevertheless, in the second embodiment a way        will be presented in which a counter value may be applied.    -   DIRECTION identifies the direction to where corresponding data        is sent. In a case of multicast the use value is always the        same, because the only applicable direction is downlink.    -   BEARER: Each point-to-point connection is labelled with the        bearer identification, which is like a banner to a group of        parameters, which are assigned only for the connection, in        question. Bearer identification along with the corresponding        parameters for the connection is sent to the UE in RRC: RADIO        BEARER SETUP message. For multicast services the support of such        prescient L3 signalling exchange is impossible to provide and        therefore no currently defined bearer concept can be extended to        cover also the multicast services. As an alternative, it may be        a valid approach to define specific new bearer types to be used        for multicast and broadcast services. If such new bearers are        introduced it is foreseen that ciphering algorithm also should        use the corresponding new bearer identification.

After removing the parameters described above the remaining parametersdo not guarantee security for the encrypted data, therefore new moresuitable parameters for multicast need to be introduced. That is, theinput parameters as COUNT-C (or at least HFN part), DIRECTION and BEARER(shown in FIG. 2) can be replaced with parameters such as GROUP ID,SERVICE ID, SUBSERVICE ID, PACKET ID (or FRAME ID) (FIG. 3) described inthe following. These parameters can be divided into four categories:subscriber related, service related, RAN related values and cell relatedvalues.

Subscriber Related Values

-   -   GROUP ID: The purpose of the GROUP ID is to represent such        value, which identifies the multicast group, which is allowed to        use of this service and which is allowed to listen this        multicast session. In the example of FIG. 1, UE's A, B, K and L        may belong to such a multicast group.    -   SUBSCRIBER ID: the purpose of the SUBSCRIBER ID is identifying        the subscriber. That is, in the example of FIG. 1, each of the        UE's has its own SUBSCRIBER ID.        Service Related Values    -   SERVICE ID: the purpose of the SERVICE ID is to identify the        multicast service type.    -   SUBSERVICE ID: The purpose of SUBSERVICE ID is to identify the        particular service.    -   PACKET ID (or frame id): The purpose of the PACKET ID is to        identify the currently received data frame or layer to SDU        received from the air interface.        RAN Related Values    -   As an alternative it may be necessary, or it may be a benefit,        to have an additional separate identity for the multicast        session in RAN, namely the RANCAST ID. It is noted that the UE        includes the RANCAST ID in a new type of PDP context activation        message to be used for (IP) multicast registration. RNC (Radio        Network Controller) shall be able to deduce the RANCAST ID from        this PDP activation message. RNC can then keep track of how many        mobiles have registered with a specific multicast session in        every cell. RNC need not know the identity of the mobiles. Also        the CN (GGSN) knows the RANCAST ID. The multicast ciphering        algorithm shall be able to include RANCAST ID as an input        parameter.        Cell Related Values    -   As an alternative the cell related values could be use to        separate the used ciphering mask between e.g. the neighbour        cells, when it is need to support e.g. such multicast services,        which allowed data receiving only in restricted area. That is,        in the example of FIG. 1, only the UE's A to G may listen to a        message which is only intended for the area of cell C1.

Thus, by using one or more of the above parameters as the inputparameter(s) shown in FIG. 3, the group of subscribers (i.e., UE) can berestricted. Namely, only those subscribers having these parameters areable to decrypt the received message.

For example, a UE of a particular subscriber knows its GROUP ID and theSUBSERVICE ID of the service to which the subscriber is subscribed.Hence, when the UE receives a multicast message, it is able to decryptthe message. When a subscriber is not subscribed to a particularservice, it may receive an encrypted multicast message, but is not ableto decrypt it since the UE does not know the corresponding SUBSERVICE IDof this particular service. In case such a UE receives the message viaSCCPCH, FACH or another suitable physical transport channel, it simplyignores the received message.

It is noted that not all input parameters have to be used. For example,in case the operator of the multicast service wishes to send a messageto all users (e.g., for giving general information) of his service, amessage may be encrypted by using no input parameter at all. In thiscase, all subscribers having the ciphering key are able to decrypt thismessage.

The input parameters described above can be used in different ways whenthe multicast content is ciphered.

GROUP ID and SUBSCRIBER ID can be different identifications, if there isneed to identify subscribers on UE level (i.e. if there is no need forthis, then these parameters can be combined). The GROUP ID is the one,which can be given to the subscriber when the subscriber makes theregistration to the service. A typical GROUP ID is the “GROUP ADDRESS”used in IP-Multicasting (IGMP (Internet Group Multicasting Protocol)Message). Whereas the SUBSCRIBER ID can be e.g. the value of IMSI (inasymmetric encryption), or it can be a new specific value, which isgiven to the subscriber when registering to the service. The idea ofusing two subscriber related values is to allow operators to remove fromthe service e.g. such subscribers, which haven't paid they fees on time,without updating the GROUP ID to all other authorised subscribers in thevery same multicast GROUP.

The SERVICE ID and SUBSERVICE ID can also either be separate values orthey can be combined as a one service related parameter. The SERVICE IDis an identification which identifies the service type, e.g. newsservice, music service, sport clips etc., whereas the SUBSERVICE IDidentifies the sent service more in detail e.g. domestic news, sportnews, international news etc. The SERVICE ID could be given to thesubscriber when the subscriber makes the registration, whereasSUBSERVICE ID is an identification which is transmitted to the UE alongwith the multicast data. The intention of this scheme is to allow theoperator to separate between different services belonging to the sameservice type.

In the following management of the ciphering keys is described.

The validity of the ciphering key can be either:

-   -   the life time of the service or    -   a specific time, which is defined by the operator (e.g. hour,        day, week, month etc.)

When the validity of the used ciphering key expires, still authorisedsubscriber is allowed to get a new ciphering key from the serviceprovider or operator, etc. The allocation of the ciphering key can bemade by the manager of the security when the UE is already in RRCconnected state for some other reason, or when the UE is in idle mode.

A time limited ciphering key can be taken care of by including anexpiring time in a subscriber register (e.g. HLR/RRC), which indicateswhen the UE needs a new ciphering key. Therefore, each time when UE/NWactivates e.g. any PDP context/RRC Connection to the UE in question, theciphering key indication shall be checked from the register and a newciphering related information should be sent e.g. by using CN levelsignalling, SMS, RRC level signalling in UTRAN or peer to peersignalling between protocol layers, which are taken care of themulticast services) if indication defines that the old one has expired.

The second type of time limited ciphering key can be handled byestablishing a signalling connection between UE and NW, in order to sendeither config SMS, or CN/UTRAN level signalling message to the UE. Basedon received information the UE can update the old ciphering key to a newone.

Another alternative is to leave the initialisation of the ciphering keyexchange to the UE, which internally should know when the ciphering keyis expired. After expiring the ciphering key the UE can either start theciphering key exchange procedures immediately, or it can wait until thesubscriber activates another application in order to initialise RRCconnection, or the subscriber has been called by third part (i.e. MTC(Mobile Terminated Call)).

In the following, storing of the security related information isdescribed.

The storing of the security related information should comply with thefollowing requirements:

-   -   The security related information needs to be stored in such a        way that it is impossible for the subscriber or any other        unauthorised user to get access to the information, both in the        NW and in UE.    -   The information needs to be secured also against all copying        transactions, which are not made by authorised service company        (e.g. the manufacturer of the SIM (subscriber Identity Module,        i.e., a storage device)).

At the network side the security related information could be storedeither in: CN (e.g. in HLR (Home Location Register), devices of theservice provider or in UTRAN (e.g. in RNC (Radio Network Controller)).

At UE side the information can be stored in SIM (Subscriber IdentityModule) or in an UE memory area.

The user should not have any access either to the SIM or UE memory areasused to store the multicast deciphering keys.

When using SIM for storing the security information, it is advantageousto increase the SIM card storage capacity in order to store allnecessary decryption keys and parameters, since currently this storagecapacity is e.g. 8 kB or 16 kB.

Next, the encryption/decryption according to the first embodiment isdescribed. The multicast encryption in a mobile network can be done inthe following way:

The starting of the decryption can be made in at least three ways:

-   -   The receiving of data from multicast related physical channel        triggers the start of the decryption. In this case the service        identifications needs to be such that UE is configured to accept        data belonging to this service (i.e. in service        subscription/registration).    -   The start of the decryption is triggered by network, by sending        pre-information about forthcoming multicast services.    -   The start of the decryption is triggered by the subscriber, upon        time when the subscriber makes the “activation” of the multicast        service. This trigger can be e.g. a pin code, or a password etc.        Without correct trigger from subscriber the decryption of the        service will not be started and subscriber will not have an        access to the service. (It is noted that the use of this kind of        trigger does not mean that the value of, e.g., the pin code        would be used for decryption as well. It is used as a key to the        service.)

The subscriber orders the service xx by sending a registration(subscribing) command to the network. The network approves theregistration (subscription), e.g. by sending an SMS to the subscriber.At the same time the network also sends the parameters, which are neededto generate the correct decryption key to the mobile so that it is ableto decrypt the subscribed multicast messages.

As an alternative, it may be necessary to standardise the interactionbetween the UE and the service provider to enable also other mechanismsthan SMS, e.g. WAP.

The encryption and decryption functions are made more efficient by usingsymmetric cryptography. Symmetric cryptography means that the message isencrypted and decrypted by the same key.

The decryption key sent from the network to the subscriber's SIM shallnot be shown to the subscriber. The decryption key (i.e., the cipheringkey for decryption) is generated from a basic value (e.g., an individualservice identification (which may be individual for each service) andfurther key generation related information, i.e., parameters, or may begenerated only from the key generation parameters. The basic value (ifused) may be written in the SIM or the memory of the UE duringsubscribing to the multicast service and, advantageously, is not sentvia the radio interface. The further key related information orparameter may be a random number generated by the network. This randomnumber may be generated based on some or all of the input parametersdescribed above.

The transmission of the parameters is described in more detail in thefollowing.

According to the prior art, authentication parameters are included in anAuthentication and Ciphering Request message, and the MS verifies theparameters. For multicast services this kind of procedure can not beintroduced, because no authentication is provided between CN and UEs.

Thus, according to the first embodiment, some of the parameters aretransmitted upon registration phase. This can be done either in clearform (i.e. all parameters are readable) or a similar system as presentedabove can be used (i.e. from the parameters, a random number can begenerated, which is sent to the UE e.g. inside the above mentionedconfig SMS). The some of the required parameters could be received fromthe system broadcast messages (SIB). This kind of information couldconsist of cell related information.

The rest of the information could be sent along with the multicast data,e.g. the above described PACKET ID.

Of course it is possible that all parameters, which are transmitted uponregistration phase are not necessarily used for Ck generation. Howeverin that case they are used as a input parameters to provideciphering/deciphering.

That is, the parameters used as input parameters for the cipheringalgorithm may also be used for generating the ciphering key Ck, and theparameters used for generating the ciphering key Ck may be used forciphering and deciphering.

Multicast messages can now only be opened by SIMs, which have thecorrect decryption key.

The encryption (and decryption) key shall be changed in a defined timeframe. The time frame can be defined by operator. The new key generationrelated information is sent to SIM using a multicast message, which isencrypted with the previous encryption key or by using some of the otherdata transmission mechanisms, as described above in the chapter onmanagement of the ciphering keys. That is, the key generation relatedinformation may be sent when the user entity registers with a multicastservice, or when a multicast transmission is activated. Alternatively,there may be a plurality of key generation related information parts(e.g., two different random numbers), a first part of which may be sentduring registration with the service, and a second part may be sent onactivation of the multicast service.

The encryption algorithm can be chosen freely, but it must be efficientenough to allow the normally used encryption function f8 to be used withthe ciphering key length 128 bits.

The embodiment described above can be implemented in two different waysfrom the cryptograhic point of view.

Firstly, a symmetric ciphering can be applied. That is, the same key isused for the encryption function and for the decryption function. Thus,only one key is needed, which simplifies the procedure.

Secondly, an asymmetric ciphering can be applied. That is, encryption isdone by a recipients public key and can be decrypted only by arecipient's secret key. The asymmetric function is more secure, but onthe other hand slower than symmetric ciphering.

Thus, in case of a multicast service offering general information forwhich a high level of security is not required, the best mode ofimplementation is to use the symmetric ciphering.

Summarising, the invention suggests some modifications to ciphering keyallocation, input parameters for ciphering algorithms and management ofthe ciphering keys to overcome the problems how to restrict thereception of point-to-multipoint data to a specific group of subscribersbecause the current ciphering is designed for point-to-pointconnections.

Ciphering key allocation: The information, which can be used to definethe correct multicast ciphering key, can be allocated to the subscriberwhen the subscriber registers with the multicast service or it can begiven to the UE each time before the multicast data transmission isactivated or as the peer to peer signalling connections between layersto support multicast data transmission on UTRAN and UE side.

Modified input parameters for the ciphering unit: Such input parametersas COUNT-C, DIRECTION and BEARER (see FIG. 2) can be replaced withparameters such as GROUP ID, SUBSCRIBER ID, SERVICE ID, SUBSERVICE ID,PACKET ID and CELL+RAN related information (see FIG. 3).

Management of the ciphering keys: The validity of the ciphering key canbe either the life time of the service or a specific time, which isdefined by the operator.

Next, a second embodiment is described. As mentioned in connection withthe description of the first embodiment, in particular the use of acounter value (COUNT_C) as an input parameter is problematic inmulticast (PTM) services. However, according to the second embodiment aprocedure is used by which nevertheless the counter value can be used.In this way, existing UMTS security mechanisms can be used to protectalso multicast traffic. Thus, the features according to the secondembodiment fit especially well for 3^(rd) Generation UMTS networks sincethe presented model utilizes the security features already available inthe system.

In detail, in the description of the second embodiment, means arepresented to utilize UMTS confidentiality protection mechanism in mobilePTM environment. UMTS confidentiality protection is originally designedfor point to point (PTP) communication environment and it cannot bedirectly used for this purpose as such. According to the secondembodiment, however, it is described how UMTS confidentiality protectioncan be adapted to PTM communication environments. In this context a PTMservice is understood as a unidirectional data delivery from the networkto a group of mobile terminals. Because the resources in the radio linkare limited, the goal is to minimize uplink signalling during PTM datareception. This means that e.g. when beginning PTM data reception, nosignalling between MS and network is allowed.

The UMTS confidentiality protection is based on a shared secret key (K)that is stored at the end user's USIM in the user entity, i.e., mobilestation (MS), and in Authentication Center in the network. USIM itselfis physically a part of UICC (Universal Integrity Circuit Card), i.e. itresides in a smart card. The end user has no access to K (on USIM). Thenetwork delivers a nonce value RAND in plain text over the radio link tothe MS. From these two values (K and RAND) both the MS and the networkcompute a confidentiality key (CK) which is then used for symmetricencryption between MS and radio access network. For encryption, anencryption algorithm is used. An example for such an encryptionalgorithm is the f8 encryption algorithm, which is usually applied inUMTS. The encryption algorithm produces a key stream, which is XORedwith the plain text to be delivered to the other communicating party.The f8 encryption algorithm takes four input parameters: CK, countervalue, bearer identifier and direction value.

This model cannot be directly applied to PTM communication because thereis no shared secret key among all the potential receivers and becausethe f8 key stream generation algorithm uses such input parameters thatare subscriber dependent. Thus, to make f8 to work also for PTMconnections, a shared key (Ks) should be delivered to all such potentialreceivers that will participate a certain PTM session. This could bedone over a secured PTP connection between each user willing toparticipate in the upcoming PTM session before the actual session. Thewillingness to participate in an upcoming PTM session may be done e.g.by some kind of subscription procedure, which is not further discussedhere. It is assumed that such a secure Ks delivery mechanism exists andKs is stored in the MS in such a way that the user cannot have directaccess to it (stored e.g. on USIM or in a terminal memory that is notaccessible for the user). This way the user may not forward Ks toillegitimate parties. Ks could be valid for some predefined time period,e.g. a day or a week.

Ks is not directly used as an input parameter for f8, but it is used asa parameter for generating the actual PTM encryption/decryption keyKptm. As another input parameter for the Kptm generation algorithm arandom nonce value RAND′ is used. RAND′ can be delivered over anunprotected PTM channel to the receivers. This way a new session key canbe easily established by transmitting a new RAND′ value to the receiverswhich can be used for new Kptm generation. The most importantrequirement for the derivation algorithm is that it should be one-way:even if an attacker would know both RAND′ and Kptm he would have nochance in finding out Ks. Namely, the algorithm that is used tocalculate Kptm (from RAND′ and Ks) is public. Thus, anybody who knowsRAND′ and Ks can figure out Kptm. The strength of the crypto system isbased on the secrecy of Ks—it is known only by the authorized users. Ifan attacker knows RAND′ and Kptm, he can decrypt the content as long asthe Kptm is valid (i.e. as long as RAND′ stays the same). But when a newRAND′ value is taken into use, the attacker has no way of calculatingthe new Kptm because he does not know Ks (he cannot derive it from Kptmand RAND′).

The new Kptm can be taken into use at a certain time—this time valuecould be delivered in conjunction with RAND′ value. To enable mobileusers to join the session at any time, the RAND′ must be sent via theunprotected PTM channel periodically with quite a small interval, e.g.every 5 seconds.

The algorithm that derives Kptm from Ks and RAND′, of course, has to bethe same for both the terminal side and the network side. If thederivation algorithm is in USIM on the terminal and it is done always inthe home network on the network side then the algorithm does not have tobe standardized but instead it could be operator-specific. However, itis anticipated that it could be possible to offer these multicastservices also for roaming users, hence the derivation algorithm couldalso be located in a visited network.

In the other problem, related to f8 input parameters, some modificationsto these parameters has to be made to enable its usage in PTMencryption/decryption. The session key Kptm computed from Ks and RAND′can be used as a CK parameter. The direction value (DIRECTION, asdefined in the first embodiment) tells whether the delivered data isuplink (i.e. from MS to RAN) or downlink (i.e. from RAN to MS). Thisparameter can be used as such i.e. it is set to value downlink, becausePTM data is originated from the network. The bearer id value (or asubstitute for it which is also a possibility since the bearer id may bereplaced with some other identifier with the same length) can bedelivered to MSs at the same time as Ks is delivered via a secured PTPchannel. The most problematic parameter is the counter value because itsvalue is not constant but changes during message exchange over thesecured channel. In PTP the RAN and MS are synchronized at connectionsetup and thus they can use this counter value in a synchronized mannerduring the connection. In PTM the situation is different, since there isno signaling connection between MS and the network when beginning PTMdata reception and therefore RAN and MSs cannot be synchronized. Also,because there are multiple receivers that join at varying times to thesession, staying in synchronization is very hard to implement.

The solution to this problem is to deliver the counter value inconjunction with the encrypted content packages over the air link. Atleast the most significant part of the counter value that is in use inthe beginning of the sending of the content packets is transmitted toall receivers. After that the receivers and the sender are synchronized.For the rest of the connection they are able to maintain thesynchronization of counter values by normal synchronization meansprovided by 3G UTRAN. In this case, the most significant part of thecounter is never more transmitted but it is implicitly maintained insync as the least significant part is sent explicitly.

This solution does not work for receivers who join the session at somelater phase. To allow also this, the whole counter value (e.g., COUNT_Cas defined in the first embodiment) should be sent with regular timeintervals. Thus, at this time intervals also the receiver who joinslater has all the required parameters and can apply f8 decryption to thereceived PTM content.

The solution according to the second embodiment is described byreferring to FIG. 4. In the figure ‘E[Kptm] ( . . . )’ means that thedata within the braces is encrypted with the key Kptm. The used deliverychannel type is also given with each signal in the diagram. In detail,PTP indicates a point to point connection, whereas PTM indicates a pointto multipoint connection.

The first signal S1 presents the procedure in which the shared secretkey Ks and bearer identifier (e.g., parameter BEARER as defined in thefirst embodiment) of the PTM session are delivered over a secured PTP(point-to-point) connection to a session's group member. Instead of thebearer identifier (BEARER), also another similar identifier of the samelength could be used.

In the second signal S2, the RAND′ value used for session key generationis delivered in plain text over a PTM channel, which every receiver maylisten to.

From these parameters (Ks and RAND′) a subscribed user may compute thesession key Kptm. These values are also stored at the network side (insome register, e.g. in AuC) and the same calculations can be carriedout. Kptm is passed from the core network to RAN (actually RNC, signalS3).

Content originating from the core network comes in plain text (signalS4) to the RAN which encrypts it with Kptm. This encrypted signal withthe indication of used counter value is delivered over PTM connection tothe receivers (signal S5). Thus only subscribed receivers may decryptthe content since only they have the required session key Kptm.

With certain time periods the Kptm may be changed by delivering a newRAND′ value to the receivers and a time value which indicates the timein which the value comes into effect. Just like described above, theterminals and the network compute a new Kptm and start using it at thegiven time. This operation can be called as re-keying. It might berequired to deliver two different RAND′ values for the same time,because a subscriber might begin content reception right in the middleof the re-keying phase when the previous key is still in use but the newRAND′ value is already being delivered. Thus the new receiver maycompute both the Kptm that is currently in use (and begin data receptionimmediately) and the new Kptm (to be prepared to receive the content inthe near future).

With the approach described here multiple benefits can be gained:

-   -   Using existing UMTS encryption algorithms the changes to the        network elements can be kept in minimum.    -   Uplink signaling is not required to take a new key in use during        a session.    -   Parameters for Kptm can be delivered using a shared unencrypted        channel. Thus there is no need for PTP signaling connections for        this purpose.

In the following, some alternatives to the second embodiment aredescribed.

As a first alternative, the RAND′ values used for establishing a newsession key could be also delivered in conjunction with Ks and bearer iddelivery over an encrypted PTP connection. In this approach there shouldbe a list of RAND's and the validity times for these values. This waythe MS could compute Kptm and the use of unencrypted PTM channel forRAND′ delivery would be unnecessary. In this way, the security can beimproved since also the RAND′ values are delivered over a secureconnection. This, however, requires that a lot of RAND′ and timing datahave to be stored such that large memory resources of an MS have to beoccupied.

As a second alternative, the delivery of RAND′ could be also done usingencrypted PTP connections to each session member. The benefit of thisre-keying method is that the member could also inform the networkwhether it wants to quit or continue its membership. Therefore a morefine-grained membership duration information would be generated andcould be used e.g. for charging purposes. However, there would be a lotof signaling between the network and MS.

Thus, the preferred way to implement RAND′ delivery is as describedabove, namely by using unencrypted PTM channel. This way the memoryrequirements of the encryption are kept in minimum.

As described above, the delivery of the counter value with the encryptedcontent is preferred procedure according to the second embodiment. Inpractice, the suggested method of delivering this value unencrypted isthe only possibility. Namely, if the counter value would also beencrypted, the MS would have no means to figure out the counter valuesince the decryption depends on it. If the counter value of the nextpacket would be included in encrypted form to a packet, there would alsobe problems. An MS joining a session would need the initial value of thecounter to be able to decrypt the first packet it receives. To get thisinitial value, some new mechanism should be introduced to preventunnecessary signalling. On the other hand, basically the counter valueis not secret information in the current UTRAN security architecture.The START parameter indicates the COUNT value in the beginning of an RRCconnection; later COUNT values are changing but an eavesdropper can alsomaintain in sync about which COUNT value is in use.

In the following, the main features according to the second embodimentare shortly summarized. The usage of the confidentiality protectionmodel of UMTS is not directly possible as such in point to multipoint(PTM) environment e.g. because the confidentiality key generationalgorithm uses subscriber dependent input parameters (secret key). Amain idea according to the second embodiment is to deliver the countervalue in conjunction with the content stream (in plain text via PTMchannel), thus enabling the receivers to decrypt the content. Thedecryption key can be updated periodically by sending a new RAND′ valueto the receivers. With this approach, no additional point to pointsignalling between the network and the terminal is required and thusnetwork resources are saved.

It is noted that the second embodiment is not limited to the use of thef8 encryption algorithm, but that instead other encryption algorithm maybe used which also use at least a counter value as an input parameter,and preferably also use a random number as an input parameter.

Furthermore, according to the second embodiment the counter value(COUNT_C) is delivered unencrypted together with the encrypted data(signal S5 in FIG. 4). Alternatively, the counter value may also betransmitted via a PTM channel (similar to the transmission of the RAND′value in signal S2 of FIG. 4). In this way, the counter value may betransmitted to the user entity at regular intervals independently of thedelivery of the encrypted data packets. In this case, however, thereshould be some kind of association between counter value and datapackets. Otherwise, it would not be known which counter value should beused to decrypt a certain packet.

As a further alternative, also the RAND′ value may be transmitted in thesame way as the counter value, i.e., together with encrypted datapackets (as in signal S4 of FIG. 4).

The description of the second embodiment is emphasised on theencryption, however, the same procedures also apply for the decryption,as described in more detail in the first embodiment.

According to the second embodiment, Kptm is computed in the corenetwork, as illustrated in FIG. 4. However, alternatively it can also becomputed in the RNC. In this way, Ks and RAND′ would have to betransmitted also to RNC.

The above description and accompanying drawings only illustrate thepresent invention by way of example. Thus, the embodiments of theinvention may vary within the scope of the attached claims.

In particular, the first and the second embodiment can freely becombined. For example, the additional parameter (e.g., subscriberrelated parameter and/or cell related parameter) described in the firstembodiment may also be used in the second embodiment in order to enhancesecurity. Furthermore, the delivery of the parameters in the secondembodiment may be performed in a similar way as in the first embodiment.For example, parameter delivery on registration to a multicast servicemay be performed using SMS or WAP.

1. A method for transmitting a message to a plurality of user entitiesin a network by using a multicast service, comprising the steps ofencrypting a multicast message by using ciphering in a multicast servicecontrol device, and sending the encrypted multicast message from themulticast service control device to the plurality of user entitiescharacterized in that ciphering is performed by using a ciphering keyand at least one input parameter, wherein the input parameter comprisesat least one subscriber related value, and/or at least one servicerelated value, and/or at least one network related value for identifyinga particular network, and/or at least one cell related value foridentifying a particular cell.
 2. The method according to claim 1,further comprising the step of decrypting the encrypted multicastmessage in each user entity individually.
 3. The method according toclaim 1, wherein the ciphering key is the same for encrypting anddecrypting.
 4. The method according to claim 1, wherein a firstciphering key is used for encrypting, and a second ciphering keydifferent from the first ciphering key is used for decrypting.
 5. Themethod according to claim 1, wherein the ciphering key is changed in adefined time frame.
 6. The method according to claim 1, whereinciphering key generation related parameters are sent to the user entitywhen the user entity registers with a multicast service.
 7. The methodaccording to claim 1, wherein ciphering key generation relatedparameters are sent to the user entity when a multicast transmission ofencrypted multicast messages is activated.
 8. The method according toclaim 1, wherein the ciphering key is stored in a memory of the userentity.
 9. The method according to claim 1, wherein the ciphering key isstored in a subscriber identification module (SIM).
 10. The methodaccording to claim 1, wherein the ciphering key is not accessible forthe user of the user entity.
 11. The method according to claim 1,wherein the subscriber related value comprises a group identificationfor identifying a group of subscribers which are allowed to receive themessage.
 12. The method according to claim 2, wherein the subscriberrelated value comprises a subscriber identification for identifying aparticular subscriber.
 13. The method according to claim 1, wherein theservice related value comprises a service identification for identifyinga service type.
 14. The method according to claim 1, wherein the servicerelated value comprises a sub-service identification for identifying aparticular service.
 15. The method according to claim 1, wherein theservice related value comprises a frame identification for identifying aparticular data frame.
 16. The method according to claim 1, wherein fordecrypting, the input parameter used for encrypting is used.
 17. Themethod according to claim 16, wherein the input parameter is stored in amemory of the user entity.
 18. The method according to claim 17, whereinthe input parameter is stored in a subscriber identification module(SIM).
 19. The method according to claim 16, wherein the input parameteris not accessible for the user of the user entity.
 20. The methodaccording to claim 16, wherein the parameters are sent to the userentity upon registering to a service.
 21. The method according to claim1, wherein the receiving of multicast related data triggers the start ofthe decryption.
 22. The method according to claim 1, wherein the startof the decryption is triggered by the network, by sendingpre-information of a multicast message to be sent.
 23. The methodaccording to claim 1, wherein the start of the decryption is triggeredby the subscriber.
 24. The method according to claim 23, wherein thetrigger is a pin code or a password.
 25. The method according to claim1, wherein the multicast message is sent via a single physical channel.26. The method according to claim 1, wherein for encryption anencryption algorithm is used which uses at least a counter value as aninput parameter, which is delivered to the plurality of user entities.27. The method according to claim 26, wherein the encryption algorithmis an f8 encryption algorithm.
 28. The method according to claim 26,wherein the counter value is delivered to the plurality of usersunencrypted together with encrypted data (S5).
 29. The method accordingto claim 27, wherein a session key (Kptm) is calculated from a sharedkey (Ks) and a random number (RAND, RAND′), the session key being usedas a further input parameter of the encryption algorithm, and whereinthe random number is updated and sent to the plurality of user entitiesat certain times.
 30. The method according to claim 29, wherein therandom number is updated at regular time intervals.
 31. The methodaccording to claim 29, wherein the random number is deliveredunencrypted (S2) to the plurality of users.
 32. The method according toclaim 29, wherein the shared key is delivered to the plurality of usersvia a secure channel (S1) via a point-to-point connection.
 33. Themethod according to claim 29, wherein a bearer identifier (BEARER) isused as a further input parameter for the encryption algorithm, andwherein the bearer identifier is delivered to the plurality of users viaa secure channel (S1).
 34. A multicast service control device fortransmitting a message to a plurality of user entities in a network byusing a multicast service, wherein the device is adapted to encrypt amulticast message by using ciphering, and to send the encryptedmulticast message to the plurality of user entities. characterized inthat the device is adapted to perform ciphering using a ciphering keyand at least one input parameter, wherein the input parameter comprisesat least one subscriber related value, and/or at least one servicerelated value, and/or at least one network related value for identifyinga particular network, and/or at least one cell related value foridentifying a particular cell.
 35. The device according to claim 34,wherein the ciphering key is changed in a defined time frame.
 36. Thedevice according to claim 34, wherein the subscriber related valuecomprises a group identification for identifying a group of subscriberswhich are allowed to receive the multicast message.
 37. The deviceaccording to claim 34, wherein the subscriber related value comprises asubscriber identification for identifying a particular subscriber. 38.The device according to claim 34, wherein the service related valuecomprises a service identification for identifying a service type. 39.The device according to claim 34, wherein the service related valuecomprises a sub-service identification for identifying a particularservice.
 40. The device according to claim 34, wherein the servicerelated value comprises a frame identification for identifying aparticular data frame.
 41. The device according to claim 34, wherein themulticast message is sent via a single physical channel.
 42. The deviceaccording to claim 34, wherein the device is adapted to use anencryption algorithm for encryption, which algorithm uses at least acounter value as an input parameter, and to deliver the counter value tothe plurality of user entities.
 43. The device according to claim 42,wherein the encryption algorithm is an f8 encryption algorithm.
 44. Thedevice according to claim 42, wherein the device is adapted to deliverthe counter value to the plurality of users unencrypted together withencrypted data (S5).
 45. The device according to claim 42, wherein thedevice is adapted to use a session key (Kptm) as a further inputparameter of the encryption algorithm, the session key being calculatedfrom a shared key (Ks) and a random number (RAND, RAND′), to update therandom number and to send the random number to the plurality of userentities at certain times.
 46. The device according to claim 45, whereinthe random number is updated at regular time intervals.
 47. The deviceaccording to claim 45, wherein the device is adapted to deliver therandom number unencrypted (S2) to the plurality of users.
 48. The deviceaccording to claim 45, wherein the device is adapted to deliver theshared key to the plurality of users via a secure channel (S1) via apoint-to-point connection.
 49. The device according to claim 45, whereinthe device is adapted to use a bearer identifier (BEARER) as a furtherinput parameter for the encryption algorithm, and to deliver the beareridentifier to the plurality of users via a secure channel (S1).
 50. Auser entity in a network, which is adapted to receive an encryptedmulticast message transmitted to a plurality of user entities in anetwork by using a multicast service, and to decrypt the encryptedmulticast message by using ciphering, characterized in that the userentity is adapted to perform ciphering using a ciphering key and atleast one input parameter, wherein the input parameter comprises atleast one subscriber related value, and/or at least one service relatedvalue, and/or at least one network related value for identifying aparticular network, and/or at least one cell related value foridentifying a particular cell.
 51. The user entity according to claim50, wherein the ciphering key is changed in a defined time frame. 52.The user entity according to claim 50, wherein the user entity isadapted to receive ciphering key generation related information when theuser entities registers with a service of sending encrypted messages toa plurality of user entities.
 53. The user entity according to claim 50,wherein the user entity is adapted to receive ciphering key generationrelated information when a transmission of encrypted messages to aplurality of user entities is activated.
 54. The user entity accordingto claim 50, further comprising a memory for storing the ciphering key.55. The user entity according to claim 50, further comprising asubscriber identification module (SIM) for storing the ciphering key.56. The user entity according to claim 50, wherein user entity isadapted to protect the ciphering key such that it is not accessible forthe user of the user entity.
 57. The user entity according to claim 50,wherein the subscriber related value comprises a group identificationfor identifying a group of subscribers which are allowed to receive themessage.
 58. The user entity according to claim 50, wherein thesubscriber related value comprises a subscriber identification foridentifying a particular subscriber.
 59. The user entity according toclaim 50, wherein the service related value comprises a serviceidentification for identifying a service type.
 60. The user entityaccording to claim 50, wherein the service related value comprises asub-service identification for identifying a particular service.
 61. Theuser entity according to claim 50, wherein the service related valuecomprises a frame identification for identifying a particular dataframe.
 62. The user entity according to claim 50, further comprising amemory for storing the input parameter.
 63. The user entity according toclaim 50, further comprising a subscriber identification module (SIM)for storing the input parameter.
 64. The user entity according to claim50, wherein the user entity is adapted to protect the input parametersuch that it is not accessible for the user of the user entity.
 65. Theuser entity according to claim 50, wherein the user entity is adapted toreceive the input parameters upon registering to a service.
 66. The userentity according to claim 50, wherein the user entity is adapted suchthat the start of receiving multicast related data triggers the start ofthe decryption.
 67. The user entity according to claim 50, wherein theuser entity is adapted such that the start of the decryption istriggered by the network, by receiving pre-information of a multicastmessage to be received.
 68. The user entity according to claim 50,wherein the user entity is adapted such that the start of the decryptionis triggered by the subscriber.
 69. The user entity according to claim68, wherein the trigger is a pin code or a password.
 70. The user entityaccording to claim 50, wherein the multicast message is sent via asingle physical channel.
 71. The user entity according to claim 50,wherein the device is adapted to use a decryption algorithm fordecryption, which algorithm uses at least a counter value as an inputparameter, and to receive (S5) the counter value from a network controldevice.
 72. The user entity according to claim 71, wherein thedecryption algorithm is an f8 decryption algorithm.
 73. The user entityaccording to claim 71, wherein the user entity is adapted to calculate asession key (Kptm) from a shared key (Ks) and a random number (RAND,RAND′), and to use the session key a further input parameter of thedecryption algorithm.
 74. The user entity according to claim 73, whereinthe user entity is adapted to receive the shared key via a securechannel (S1).
 75. The user entity according to claim 73, wherein theuser entity is adapted to use a bearer identifier (BEARER) as a furtherinput parameter for the decryption algorithm.
 76. A network systemcomprising a multicast service control device according to claim 34 anda user entity in a network, which is adapted to receive an encryptedmulticast message transmitted to a plurality of user entities in anetwork by using a multicast service, and to decrypt the encryptedmulticast message by using ciphering, characterized in that the userentity is adapted to perform ciphering using a ciphering key and atleast one input parameter, wherein the input parameter comprises atleast one subscriber related value, and/or at least one service relatedvalue, and/or at least one network related value for identifying aparticular network, and/or at least one cell related value foridentifying a particular cell.
 77. The network system according to claim76, wherein the encryption and the decryption is performed by using aciphering key.
 78. The network system according to claim 77, wherein theciphering key is the same for encrypting and decrypting.
 79. The networksystem according to claim 77, wherein a first ciphering key is used forencrypting, and a second ciphering key different from the firstciphering key is used for decrypting.
 80. The network system accordingto claim 77, wherein the multicast service control device is adapted tosend ciphering related parameters to the user entity when the userentity registers with a service sending encrypted messages to aplurality of user entities.
 81. The network system according to claim77, wherein the multicast service control device is adapted to sendciphering related parameters to the user entity when a transmission ofencrypted messages to a plurality of user entities is activated.